四年前我大四,進軟體業實習,第一份軟體開發實習就被火了,所以趕緊找第二份,找到的實習缺願意讓我做軟體測試,開發Python腳本。(過來人誠心建議你別過來,用程式語言挑工作有時不一定是明智的選擇)
那時候我以為,這份工作的難處是寫程式。
具體一點說:怎麼把手動測試的步驟,轉成一份夠好的自動化測試腳本。
好讀、好維護、結構清楚。
我幾乎前兩個月的注意力都放在這件事上:
這個變數該叫什麼、這段要不要抽成函式、同樣的流程重複三次是不是該包起來。
我當時覺得,只要這件事做得夠好,我就是一個合格的測試工程師了。
主管問的第一種問題
我的主管會來看我的程式碼,然後問我:
「為什麼你這個變數這樣命名?」
「為什麼你這個步驟這樣寫?」
一開始我以為他在挑格式。後來我發現不是。
他真正在問的是另一件事:這份測試程式碼,
如果要跟 production code 一起交付出去,交得出去嗎?
我答不出來。
不是因為我不會辯解,是因為我根本沒有想過這件事。
在我腦中,測試腳本是我自己用的東西,能跑、能抓到問題就好。
「要跟 production code 一起交付」這個標準,對我來說完全是新的。
它意味著這份程式碼會被別人讀、會被別人改、會在我離開之後繼續被別人維護,而不是隨著我的期中期末考結束後就結束生命週期。
我那時候是個大四的社會菜鳥,沒有自信,也沒有語言回答這種問題。所以我通常就是點頭,回去改。
主管問的第二種問題
另一種問題出現在測試計劃上。
他看完我寫的計劃,會說:「所以你確定你寫完整了嗎?有沒有哪裡還有漏?」
他問得算溫和,也算有熱忱;他不是丟下一句「重寫」就走,他會一直引導我,要我自己再想想還有哪裡缺。
我現在回頭看,知道那是很不錯的帶法,就是他真的身材練得太好,講什麼都讓我很有壓力。
但當時我心裡真正的感覺是:你既然看得出來哪裡有缺,為什麼不直接告訴我?
他為什麼知道我漏了什麼
這件事我過了很久才想明白,而答案一點都不神祕。
我的主管是整個系統架構最清楚的人。這個新功能要怎麼開發,他已經跟 PM 談過了。哪些需求當初就沒有講清楚、哪些地方是靠雙方默契補起來的、哪些邊界大家其實各有各的想像——他全都知道,因為他就在那些對話裡。
所以他看我的測試計劃,不是用一種高深的直覺在看。他是拿著一份我看不到的地圖,在比對我畫出來的路線。他一眼就看得出我沒走到哪裡,因為那些地方本來就標在他的地圖上。
而他說不太出「我為什麼知道那裡有缺」,也不是藏私。是因為那些東西對他而言是背景常識——已經內化到不需要被說出口的程度。人很難解釋自己習以為常的事。
換句話說:我跟他之間的差距,當時主要不是能力差距,是資訊差距。 我沒有進到那些對話裡,所以我手上沒有那張地圖。
這兩種問題其實是同一個問題
一個問我的程式碼交不交得出去,一個問我的計劃寫不寫得完整。它們長得不一樣,但指向同一件事:
你憑什麼說這個可以了?
這就是 QA 那個 A —— Assurance,品質保證。
有趣的是,中文的工作現場幾乎沒有人用「保證」這個詞講話。我們說「這個沒問題」「這個可以上」「這塊我 hold 不住」。RD 不太清楚 QA 到底在保證什麼,PM 也不太清楚,很多時候連 QA 自己都不清楚——因為我們手上最常用的那句「沒問題」,比 assurance 模糊太多了。它沒有範圍,沒有信心水準,沒有前提條件。
我實習的時候每天都在講「沒問題」。而我其實不知道自己在保證什麼。
這個系列要講什麼
測試的技法——怎麼設計案例、怎麼寫自動化、怎麼排優先序——網路上已經很多,寫得比我好的也很多。那是一半。
另一半,是我的主管當年說不出口、但一眼就看得出來的那個東西。接下來 30 天,我想試著把它講清楚,講給四年前那個點頭說「好我回去改」的自己聽:
怎麼看懂主管真正要什麼。
同一句「這個要測一下」,在不同的組織結構底下,是不同的擔心。
該做什麼測試。
不是「怎麼測」,是在時間永遠不夠的情況下,憑什麼決定哪些要測、哪些不測,以及怎麼把這個決定說出口。
怎麼想清楚自己要什麼。 做久了會發現,有些難受不是能力問題,是位置問題;而有些無聊其實是訊號。
我不是資深的QA Engineer Lead or Head,也不是來教組織該怎麼改的,更不是敏捷教練或顧問,他們能給由上至下的建議和理論。我寫的是另一種視角:當你什麼都不能決定、手上也沒有那張地圖的時候,你可以怎麼由下往上的把事情做對。 如果你現在就坐在那個位置上,這個系列是寫給你的。
今天帶走的一樣東西
如果能回去跟當年的自己說一句話,我會說:
當主管問「你確定寫完整了嗎」,他不是在質疑你,他是把他手上那張地圖的一角遞給你。你可以反問他一句:
「你會從哪裡開始懷疑?」
這句話不需要任何資歷或權限就能問出口,但它會把對方腦中那份你看不到的東西挖出來一點。
我當年沒問過。所以這 30 天,算是補問。
明天聊第二件事:主管要的其實不是綠燈。